Fibre Channel (FC) is a popular high-speed networking technology, which can run at speeds of two-, four-, eight- and sixteen-gigabits per second. Common situations in which FC is employed include storage area networks (SANs) in enterprise storage systems, for instance. In general, an FC network, or fabric, includes one or more FC switches, host devices like servers, and target devices like storage devices.
An FC switch can have a number of F_Ports that are connected to N_Ports of host devices and target devices. Typically, an N_Port has a single N_Port_ID associated with it, and in turn the N_Port_ID has a single worldwide port name (WWPN) associated with it. A device such as a host or target device registers the WWPN of the N_Port to which it is connected via a fabric login (FLOGI) request, and responsively receives an N_Port_ID.
However, in the case of a device that includes multiple virtual devices, such as a server running multiple virtual machines (VMs), for instance, the fact that the device connects to an FC switch via a single N_Port can be problematic. This is because it may be desired for each VM, for instance, to have its own WWPN and thus its own N_Port_ID for FC zoning and other purposes. More recently, then, N_Port_ID virtualization (NPIV) has been introduced. An FC switch that supports NPIV permits a device connected via a single N_Port to register multiple WWPNs and correspondingly receive multiple N_Port13 IDs. As such, each VM can have its own WWPN and its own N_Port_ID.
A related, but different, technology that has also been more recently introduced is N_Port virtualization (NPV). NPV addresses the tension between there being a limited number of FC domain IDs and the desire to have an increased number of FC switch ports to add more devices to an FC fabric. Specifically, each FC switch has to have its own FC domain ID. To add more devices to an FC fabric, additional FC switches have to be added so that there are available ports to which to connect the devices. However, at some point the number of FC domain IDs can run out, limiting the size of an FC fabric.
NPV ameliorates this issue, by effectively permitting NPV gateways to act as proxies to existing FC switches by in effect adding N_Ports to the switches. NPV requires NPIV at the switch level. An NPV gateway has multiple F_Ports to which to connect host and target devices, and an NP_Port that connects to an F_Port of an FC switch. From the perspective of the FC switch, the NP_Port appears as an NPIV-enabled host. As such, the WWPNs of the N_Ports of the devices connected to the F_Ports of the NPV gateway can be registered so that they receive corresponding N_Port13 IDs. NPIV is therefore used so that the NPV gateway can have multiple N_Port13 IDs.
As such, NPIV may have originally been employed so that virtual N_Ports (i.e., one per VM) could be registered with the FC fabric via their WWPNs to receive associated N_Port13 IDs. Using NPIV in conjunction with NPV permits multiple physical N_Ports connected to F_ports of an NPV gateway to be registered with the FC fabric with their WWPNs to receive associated N_Port13 IDs. The F_Ports of the NPV gateway are effectively, by proxy, F_Ports of the FC switch to which the NP_Port of the gateway is connected. An additional FC domain ID is not needed for the NPV gateway. In this way, additional devices can be added to an FC fabric without having to add FC switches and thus without having to worry about exhausting the limited number of FC domain IDs that are available.